Method and apparatus for executing software applications

ABSTRACT

Consumer electronic devices, such as e.g. high-definition movie players for removable storage media such as optical discs, may provide possibilities for advanced interactivity for the user, implemented as software applications. A question arising generally with such software applications is what the life cycle of such an application is, and who may control it. The invention provides a method for executing software applications within a playback device for audio-video data, wherein data from a first removable storage medium are read for a software application to be executed within said playback device, and the data comprise an indication defining a termination condition for the application. Based on said termination code and depending on how the medium holding the application is ejected, the application is terminated or may survive.

Related Applications

This application is a continuation of U.S. Ser. No. 11/884,698, entitled“Method and Apparatus for Executing Software Applications” filed Aug.20, 2007 and which issues as U.S. Pat. No. ______, on ______.

FIELD OF THE INVENTION

This invention relates to a method for executing or terminating softwareapplications.

BACKGROUND

Latest developments in consumer electronic devices, such as e.g.high-definition (HD) movie players for removable storage media, providepossibilities for advanced interactivity for the user. Techniques forinteractive software applications are based upon script execution, e.g.ECMAscript, or on execution of code, e.g. JAVA, that is eitherinterpreted or pre-compiled for running on a virtual machine (VM)located in the device. Such an application could e.g. be a news tickershowing text at the bottom of the picture in an overlay while e.g. a HDmovie is running and depicted on the screen. While the HD movie is readfrom the removable storage medium, the ticker application executable canalso be read from the same medium or from the local storage of theplayer. The application data can be stored e.g. in an archive file, e.g.a JAR file for Java applications. The data used by theticker-application however, i.e. the message to be displayed, can beread e.g. from a server via the Internet.

SUMMARY OF THE INVENTION

A question arising generally with software applications is what the lifecycle of such an application is, and who may control it. Especially, ifan application was read from a first removable storage medium andstarted while the medium was inserted in the player, and then thestorage medium was ejected and left the player, the usual consequencefor the running application (e.g. the news ticker) is either to continuerunning independent from any storage medium being inserted in theplayer, or to terminate immediately. In the first case the applicationprocess will usually run until the user terminates it manually, e.g. byswitching off the device. This is uncomfortable for the user,particularly in the case of consumer electronic devices. Further it isdesirable to have software applications that survive (i.e. continueexecution) also if the storage medium from which they were loaded isremoved or otherwise not accessible.

The current invention provides a method for controlling whether arunning software application being loaded from a removable storagemedium, and running on a player for this medium, should continue orterminate when this removable storage medium is ejected. In principle,the software application may also run on a different connected device ifthe connection between the player and the other device includes controllines for terminating the application. Further, the method according tothe invention is suitable for controlling whether execution of asoftware application may continue after another removable storage mediumis inserted in the player. According to the present invention, thedecision whether a running application is terminated or not upon mediumejection may depend on why the medium was ejected, and under whichconditions the application is allowed to stay alive, i.e. continuerunning.

Particularly, and assuming that a storage medium may contain a pluralityof titles from which the user may select or which may be appended orstringed automatically, these conditions may include terminating anapplication always upon title change, terminating an application onlyupon title change initiated by a user, terminating an application upontitle change when a previous title requested a particular follower titleand the next title is not the requested title, terminating anapplication unconditionally upon medium ejection, terminating anapplication upon medium ejection only if the medium ejection is causedby a user e.g. pressing a (hardware or software, i.e. displayed onscreen) eject button, terminating an application upon medium ejectionand insertion of another medium, and terminating an application uponmedium ejection and insertion of another medium, wherein the applicationrequested a particular follower medium and the actually inserted mediumis not the requested follower medium. In other words, softwareapplications according to the invention loaded from a removable storagemedium may have a defined lifetime, may request specific other removablemedia, and may continue running when the requested removable media areinserted or be terminated when other, unrequested removable media areinserted. Further, in one embodiment an application may specify aplurality of removable media that it accepts, and continues executionwhen any of the specified media is inserted while terminating whenanother medium is inserted.

According to the invention, a method for executing software applicationswithin a playback device for audio-video data read from a removablestorage medium, wherein the playback device comprises a hardware buttonand/or a software button for ejecting the removable storage medium,comprises the steps of

reading from a first removable storage medium data for a softwareapplication to be executed (preferably within said playback device), thedata comprising script code or executable code defining saidapplication, and further comprising an indication defining a terminationcondition for the application, storing said indication (preferablywithin the playback device), starting execution of said application(preferably within the playback device),

receiving a command for ejection of the first storage medium, detectingwhether the received command for ejection was initiated by the softwareapplication or by the user using said hardware and/or software buttonfor ejection,

deciding, depending on said stored indication and on the result of saiddetecting, whether to terminate or to continue the software application,and based on the decision, terminating or continuing the softwareapplication. If the application runs on another device connected to theplayback device, a further step performs sending a termination signal tothe other device in order to terminate the running process.

In one embodiment of the invention, the method for executing softwareapplications is further specified in that the step of deciding comprises

deciding to continue execution of the software application, if saidindication indicates that execution of the software application maycontinue upon ejection of said first storage medium, or if the detectingyields that the command for ejection was initiated by the softwareapplication and said indication indicates that execution of the softwareapplication may continue upon ejection of said first storage medium ifthe ejection was initiated by the software application; or

deciding to terminate said software application, if said indicationindicates termination of the software application upon ejection of saidfirst storage medium, or if said detection yields that the command forejection was initiated by the user.

In one embodiment, the method for executing software applicationsfurther comprises the steps of receiving from said software applicationa first identifier, storing the first identifier, detecting before thestep of deciding insertion of another removable storage medium, readinga second identifier from the second removable storage medium, comparingthe stored first identifier and the second identifier, and deciding,depending on said stored indication and on the result of said detectingand on the result of said comparison, whether to terminate or tocontinue the software application.

The identifiers that are read from the medium can e.g. be titleidentifiers or medium identifiers, which are equal for several or allcopies of a medium. Thus, the identifiers relate rather to contents thanto physical media, i.e. several or all copies of e.g. a particularedition of a particular movie have the same identifier. For read-onlymedia, e.g. the content provider may assign this identifier.

According to another aspect of the invention, a method for executing orterminating software applications within a playback device for removablestorage media comprises the steps of

reading a first identifier from a first removable storage medium,reading from the first medium data for a software application, startingexecution of said application e.g. on a virtual machine (VM), thendetecting a request for a particular removable storage medium,determining whether the request comes from the user or from theapplication, and if the request comes from the application then alsoreceiving an identifier identifying a requested removable storagemedium, further storing the received identifier identifying therequested removable storage medium,

ejecting the first removable storage medium, wherein execution of saidsoftware application continues, detecting insertion of a secondremovable storage medium, reading an identifier from the secondremovable storage medium,

comparing the stored identifier with the read identifier of the secondremovable storage medium, and continuing said software application ifthe compared identifiers match while otherwise terminating said softwareapplication.

In a preferred embodiment, the running software application contains anidentifier indicating whether the application is qualified for survival,i.e. if it must be terminated immediately upon ejection of the removablestorage medium it was read from. Such applications are called herein“bound”, because they are bound to a particular removable storagemedium. Other applications are called “unbound” herein, because they arenot bound to a particular medium and may continue to be executed uponcertain conditions after the storage medium they were read from isejected. This identifier relating to an application is e.g. storedwithin a list of running processes or running VM applications, andchecked either while said removable storage medium is ejected or laterwhile a new removable storage medium is inserted. In the latter case,the identifier of the new medium can be checked before terminating boundapplications, so that it is possible to continue even bound applicationsif the same medium is inserted again.

The solution given by this invention satisfies equally the contentprovider and the user of the player. On the one hand it providesadvantages with respect to security that are relevant for the contentproviders being afraid about misuse of their multimedia content, and onthe other hand it prevents the user from being annoyed by applicationsthat continue running when the user decides to eject the medium.

An apparatus according to the invention for playback of multimedia dataread from a removable storage medium, comprises a processing unit forexecuting script code or executable code, e.g. Java or ECMAscript code,a hardware and/or a software button for ejection of the removablestorage medium, means for reading from a first removable storage mediumdata for a software application to be executed within said processingunit, the data comprising script code or executable code defining saidapplication, and further comprising an indication defining a terminationcondition for the application, means for storing said indication, e.g. aregister, means for receiving a command for ejection of the firststorage medium, like the hardware and/or software button mentionedabove, means for detecting whether the command for ejection wasinitiated by the software application or by the user using said hardwareand/or software button for ejection, means for deciding, depending onsaid stored indication and on the result of said detecting, whether toterminate or to continue the software application, wherein the means fordeciding outputs a decision signal, and means for terminating orcontinuing the software application, based on said decision signal.

According to another aspect of the invention, an apparatus for playbackof multimedia data read from a removable storage medium, comprises

a processing unit for running a virtual machine (VM), means for readingfrom a first removable storage medium an identifier, means for readingfrom the first removable storage medium data for a first softwareapplication being executable on the VM, means for detecting a requestfor changing the removable storage medium, means for determining whetherthe change request comes from the user or from the application, meansfor receiving an indication of a requested identifier if the requestcomes from the application, means for storing the requested identifier,

means for ejecting the first medium, means for detecting insertion of asecond medium, means for reading a second identifier from the secondmedium, means for comparing the stored identifier with the secondidentifier, and means for terminating said software application if thecompared identifiers do not match, and for otherwise continuing saidsoftware application.

Advantageous embodiments of the invention are disclosed in the dependentclaims, the following description and the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention are described with reference tothe accompanying drawings, which shows in

FIG. 1 the life cycles of different software applications;

FIG. 2 an exemplary menu application;

FIG. 3 a flow chart for starting an interactive application;

FIG. 4 a flow chart for terminating an interactive application, whereinthe application ejects the medium;

FIG. 5 a flow chart for terminating an interactive application, whereinthe user ejects the medium;

FIG. 6 a flow chart of the process to be executed before ejecting themedium;

FIG. 7 a flow chart of the process to be executed after insertion of amedium; and

FIG. 8 an application programming interface call requesting a particularstorage medium to be inserted.

DETAILED DESCRIPTION OF THE INVENTION

Though the following examples are based on optical disc players, theinvention described herein is also applicable to other high-densitystorage media and respective players. Consumer electronics devices, likeHD movie players, often provide the option to run software applications,particularly interactive applications, like e.g. news tickers ormovie-combined games. According to the present invention, theseapplications can either be disc-bound or disc-unbound, and title-boundor title-unbound. In general all disc-bound applications will beterminated if the disc is ejected, i.e. leaving the player.

A disc-unbound application however, if started once, is potentially ableto continue being executed by the environments (i.e. the movie players)virtual machine (VM) or interpreter, regardless of a specific disc beinginserted or not. One idea of the invention is that an applicationsignals, e.g. by means of a flag or indication, if it is bound to discor not. This flag indicates if the application is a disc-bound or adisc-unbound application. The flag may also be more than a single bit,and indicate conditionally how the application should behave when thestorage medium is ejected, depending on defined conditions. AnApplication Program Interface (API) provided within the player firmwareserves to extract this information by investigating this flag for each(running) application.

A further advantage of the present invention is that it provides amechanism that allows e.g. content providers of interactive HD moviediscs to use multi-disc applications that work safe and seamless overdifferent discs. Thus, the invention improves the data security againstpiracy. Furthermore the invention ensures that the user of the HD movieplayer is able to terminate such seamless multi-disc application if helikes to. With state-of-the-art players, either the content providerwould not be able to generate multi-disc applications or the user wouldnot be able to terminate such a multi-disc application. The inventionpreserves the interest of both parties.

One idea is that in case of ejecting the disc (or finishing playback ofa title) the player (i.e. the environment) detects who initiated theejection. If the ejection was requested by an application havingrespective rights, e.g. a disc-unbound interactive application(implemented e.g. as a Java Xlet, where several Java applications may beexecuted simultaneously), the ejecting will not terminate disc-unboundapplications. Upon insertion of another disc (or starting a new titlerespectively), the conditions to continue running the disc-unboundapplications are checked further. Such conditions include e.g. that thenew title must allow for running the disc-unbound applications. This canbe further differentiated by generally allowing disc-unboundapplications, or by checking through a security framework if theinteractive application can be identified as authorized, or signed, forrunning with the new disc.

If the user directly requested the ejecting, all bound and also allunbound interactive applications are terminated. It is possible tofurther diversify unbound application termination for this case byasking the user to confirm the termination. This avoids unintendedbreaks. Furthermore it is possible to distinguish between thoseinteractive applications related to the disc just being ejected (ortitle just finished) and those interactive applications unbound to thedisc just being ejected (or title just finished). Termination of thefirst kind of applications can be generally decided by the user, as adefault, while termination of the second kind can be decided by the userseparately for each case.

Interactive applications executed on a VM or script interpreter of anadvanced interactive movie player can be started by the player or by theuser. FIG. 1 shows the life cycles of different software applicationse.g. in a player while a first disc Disc-A was ejected and currently asecond disc Disc-B is inserted. An arrow indicates where two userinitiated applications (ii, iv) start. The application life cycles canbe disc-bound (i)-(v) or disc-unbound (vi). FIG. 1 further showsdifferentiations for such disc-bound interactive applications that aretitle bound (i,ii) and such that are title-unbound (iii,iv,v).

In principle disc-bound and title-bound are very similar from a logicalpoint of view. In a simple case, a movie disc is carrying only one titlecoming from one content provider, and lifecycles of all boundinteractive applications end when this title ends, or is left.

In many cases however, a content provider could place more than onetitle on a single disc, e.g. to provide some episodes of a standarddefinition (SD) video on a high capacity disc. For solving the problemof controlling interactive applications whose lifecycle exceeds onetitle or one disc, or in other words which survives a service switch,this is very similar. The invention is (in parts) applicable in bothcases. This does however not include user actions, because when playingmultiple titles from one disc, the interaction of a user who ejects adisc and enters another disc is not necessary and therefore omitted.Also the examination of a below-explained disc_bound_flag can be skippedon title changes within one disc as for the cases (iii-v) in FIG. 1. Thefocus of explanations is on the disc-unbound application lifecycles (viin FIG. 1) that implicitly cover multiple titles located on a singledisc.

The present invention provides means for the player to distinguishbetween disc-bound and disc-unbound interactive applications, so thatthe player can determine the appropriate lifecycle for a runningapplication. One idea of the invention is that a flag associated withevery (interactive) application describes the intended usage, i.e. ifthe interactive application is a disc- (or title-) bound or a disc- (ortitle-) unbound application. A further idea is the definition of anApplication Program Interface (API) residing in the player firmware andproviding the controlled access for the disc_bound_flag informationdefined for each application. By investigating the disc_bound_flag, theplayer is able to determine the appropriate lifecycle, i.e. to reactcorrectly on a disc eject request and an interactive application startrequest.

A further advantage of the invention is that it provides a mechanism toallow the content provider of interactive HD movie discs to use seamlessmulti-disc applications and on the other hand to allow the user of aplayer to terminate such seamless application if he likes to.

In the following it is explained what is understood as a seamlessmulti-disc application. A seamless multi-disc application can be usefulto cover large volume content, e.g. TV serials or movie collectionspresented by means of one interactive application. E.g. 134 episodes ofa soap opera may be stored on twenty-two discs, making a collection, andall of the episodes from all discs utilize or offer a common interactiveapplication. This framing interactive application is visible for theuser as a uniform interface, independent from what disc of thecollection is currently inserted. The disc-unbound interactiveapplication could also serve for providing inter-disc navigation, i.e.title change across multiple discs applications, or for accumulatinginterim results of games, or for storing the viewing order etc.

Giving the content provider a tool to establish multi-disc applicationscould on the other hand create disadvantages for the user, being forcedto react on running disc-unbound interactive applications. When the usere.g. changes the disc in the movie player, aiming to play another movie,then the still active unbound application could bother him e.g. byasking to insert a special disc or by requesting the user to explicitlyquit the service. In a more dramatic case, it could force the user toswitch off the power circuit for termination. Advantageously, theinvention preserves the interest of both parties.

As depicted in the flow charts of FIGS. 3-5, the player uses a mechanismto distinguish between both kinds of terminating disc-unboundinteractive applications, as it is the player that verifies whoinitiates the disc eject or service change.

FIG. 3 shows in a flow diagram how an exemplary interactive applicationis started. Three different sources for the interactive application areincorporated handling the application that comes from the inserted disc,from the local storage of the player or from the Internet. The firstcase is the most common situation, because also in multi-discapplications the disc-unbound interactive application source willusually be located on all the involved discs. The second case could bee.g. a news ticker. The third case could typically be a studio serverfor the featured disc provided by the studio.

A security framework serves for consistency in starting any interactiveapplication, i.e. checks if the inserted disc allows for startingunknown applications or checks if the interactive application startrequest can be identified as authorized from the disc e.g. by signatureverification. The flow diagram of FIG. 3 is left at B when aninteractive application has been successfully started.

The lifecycle of the interactive application started within the firstdiagram in FIG. 3 is continued by one of the two next flow charts ofFIG. 4 and FIG. 5, but always only one out of the two. Any end state Bin a diagram is followed by either a start state B1 or a start state B2.

The flow chart of FIG. 4 shows the actions in the case that the requestto eject the disc came from a disc-unbound interactive application (e.g.a Java Xlet). The ejecting will not terminate disc-unbound applications,but the player will check, by means of e.g. the security framework andsignature verification, if the disc that is inserted next is therequested one. If the following disc is the requested one, the situationis the same as when reaching the end of FIG. 3, i.e. state B in FIG. 4is reached, and another loop of the flow chart in FIG. 3 may follow, oralso the flow chart in FIG. 4. On insertion of another, not requesteddisc (i.e. starting a new service), the user may be informed about hisaction, i.e. he is told to insert the right disc or the runningmulti-disc application the will otherwise be terminated. In case thatthe user recognizes having made an error, by rejecting a service change,the disc is ejected again (or the user ejects it) and the request forinserting the right disc is repeated. In case that the user requests theservice change, the interactive application is terminated and the endstate is reached. The new disc will start up beginning with FIG. 3again.

The flow chart of FIG. 5 shows the actions in case that the request toeject the disc came from the user. The flow chart in FIG. 5 a) shows asimple solution by terminating all bound and also all unboundinteractive applications. A more sophisticated solution is depicted inthe flow chart of FIG. 5 b). It is possible to further diversify unboundapplication termination by asking the user for confirmation of thetermination. This avoids unintentional breaks.

Furthermore it is possible to distinguish between those interactiveapplications related to the disc just being ejected, and thoseinteractive applications unbound to the disc just being ejected. Thetermination of the first kind of applications can be decided by the userin general while the termination of the second kind can be decided bythe user separately for each.

In the following, a further embodiment of the invention is describedthat gives a more detailed description of the application framework. Theexample exploits the above-explained disc_bound_flag within the movieplayer firmware to ensure that a corresponding interactive applicationkeeps running across a disc change. Also the usage of the applicationsignature is explained within the following flowcharts depicted in FIG.6 and FIG. 7.

While FIG. 6 describes what steps are processed from the movie playerfirmware when the request for ejecting a disc is directed to it, FIG. 7covers the steps processed from the firmware each time a disc enters theplayer. The described combination of a specific insertion and ejectionflow is necessary to provide multi-disc interactive applications. Itshows a solution for the problem of keeping data integrity for thecontent providers security, and also for appropriate user experience(i.e. the user should have the impression of seamlessness etc).

The flowchart of FIG. 6 is started every time when ejecting a disc isrequested. This could be requested either by the user when pressing the(hardware or software) eject button, or by an interactive multi-discapplication. While the disc-unbound interactive application is preparingthe eject request by writing the media identifier (discID) of therequested disc (or a plurality of media identifiers of a plurality ofacceptable discs) into a special purpose register (discIDregister) inadvance, the request of the user button pressing will enter theflowchart with the discIDregister being empty.

Writing the media identifier of the requested disc (or a plurality ofmedia identifiers of a plurality of acceptable discs) into a specialpurpose register need not necessarily be done by the disc-unboundapplication itself, but it can also be done by an API, by anotherservice or another application that is called or initiated by thedisc-unbound application.

In this case, the disc may be ejected immediately, but it is alsopossible to store a command for ejection, as shown in FIG. 8, so thatthe actual ejection must be confirmed by the user. This has theadvantage that the user may change his mind, and the applications maycontinue.

Since running applications are usually stored in a cache within theplayer, they may generally qualify for survival of a media change.However, since such applications may require reloading code from themedium from which they were loaded, it may be useful to have the samefull application code stored on all media that are accepted by anunbound application, so that reloading is possible.

The firmware is analysing the status of discIDregister, and when therequest came from a user then it terminates all interactiveapplications. Another detail not depicted has already been explainedwithin FIG. 5 a). After terminating all interactive applications, themovie player physically ejects the disc, and the flow chart is at itsend.

When the firmware analysis detects a discID within the discIDregister,it starts to loop across all running interactive applications, checkingfor each if it is a disc-unbound application, if it is signed and alsoif the application is stored in the players cache memory. Only when allconditions are fulfilled, the application keeps running when the discleaves the player.

In all other cases the examined interactive application is destroyed.Checking the signature of an application ensures that no unauthorizedapplication (malicious or pirate application) is able to pass thesecurity framework. Checking if the disc-unbound application is cachedensures that the application is able to survive when the disc leaves theplayer. If the application would not be stored in the cache, it wouldprobably “starve”, i.e. be unable to continue, because the disc fromwhich it was loaded has gone and there is nothing left to reload from.

When the loop across all running applications ends, only the signed andcached disc-unbound applications are still running, and with thephysically eject of the disc the flow chart is at its end.

A further idea of the invention, which is not depicted in theflowcharts, concerns the case of leaving the loop across all runninginteractive applications. When leaving the loop and thus allapplications have been terminated, then also the discIDregister shouldbe cleared, in order to avoid a warm start for the next disc. This willfurther improve data consistency and application robustness.

FIG. 7 depicts the flowchart that the movie players firmware will enterevery time when a disc is inserted. First it is checked if any mediaidentifier (e.g. discID) is stored in the discIDregister. This indicatesthat an interactive application requested the user to insert anotherdisc. It is possible though that no application continues to run.

If the discIDregister is empty, the disc will start in initial mode fromscratch. Starting form scratch is called a “cold” start, which destroysall running interactive applications and also clears the discIDregister.In case that a discID is stored in the discIDregister, a second checkwill prove if the stored discID really matches that of the inserteddisc. If this is not the case, the user may be warned and be given helpto decide how to proceed.

Either the user intentionally inserted another disc, then allapplications running are terminated and a cold start of the discfollows, or the user made a mistake and then gets another chance toinsert the correct disc, as shown in the back loop to the disc insertionflow chart of FIG. 7.

If the discID of the newly entered disc matches the discID stored withinthe discIDregister, the discIDregister is cleared and a newinvestigation loop across all running applications is executed. It ischecked if the running application is also part of the new title on thenew disc, and if it has the same signature as that located on the disc.

Both checks improve security and robustness. Only when both checks aresuccessfully passed the disc-unbound interactive application remainsrunning. If the application was not listed within the new disc (or titleon the new disc), it is destroyed. If the application signature of discand cache mismatch, the application from disc is restarted to keepconsistency. The loop ends with a warm start of the disc. This meansthat the disc-unbound interactive application continues e.g. to controlthe service for playback.

Another variation not depicted in FIG. 7 is for the case that noapplication at all is running when leaving the application check loop.In this case also a cold start of the disc should be executed.

An example is shown in FIG. 2. A disc player PL loaded from a first discD1 having an associated identifier disc_ID_1 a menu application, whichis displayed on a screen SCR. The displayed menu contains a list ofoptions for the user to select, a software eject button SW_EJ_B and a“Cancel” button C_B. The player has a hardware eject button HW_EJ_B.When the user selects a title, e.g. Part_31, the menu applicationdetermines from its internal list that the selected item is on anotherdisc than the one being currently inserted, and displays a message forthe user to insert the requested disc. Internally, the applicationstores the identifier for the requested disc discID_2 in a dedicatedregister (discIDregister). E.g. the currently inserted disc may now beejected when the user confirms his selection, e.g. by selecting againhis choice Part_31, and the user may now eject the current disc with thehardware or software eject button. Since the application has stored anidentifier for a requested next disc (disc_ID_2) in the dedicatedregister, the ejection is classified as not user-initiated butapplication-initiated. Therefore disc-unbound applications, like themenu application as such, may continue to run. If the user changes hismind, he may still press the Cancel button C_B. This may e.g. have theeffect that the already open disc tray is closed again, and theapplication returns to its previous state.

Generally, consumer electronic devices may provide possibilities foradvanced interactivity for the user, implemented as softwareapplications. The invention provides a method for executing softwareapplications within a playback device for audio-video data, wherein datafrom a first removable storage medium are read for a softwareapplication to be executed within said playback device, and the datacomprise an indication defining a termination condition for theapplication. Based on said termination condition and depending on howthe medium holding the application is ejected, the application isterminated or may survive.

Another example for an application is a guide-application constructed tocover multiple discs. Entering the first disc of the serial starts theguide-application, and the guide-application will survive any discchanges until a disc that is not part of the serial enters. Thisprovides for the user a seamless experience. The invention ensures thatonly authorized applications may automatically survive disc changes,while non-matching interactive applications are terminated.

The invention is applicable to all kinds of storage media andcorresponding players, which are today particularly optical discs likeDVD, HD-DVD or Blu-ray discs and their corresponding players. Theinvention is particularly useful for players that are able to runinteractive software applications.

Examples for software applications are a news ticker connecting to theInternet, or organizing software in a personal-data-assistant (PDA)manner that may be modified depending on the currently inserted disc,e.g. calendar manager that reads data from a local storage like ahard-disc drive (HDD).

1. Apparatus for determining the lifetime of a software applicationassociated with AV data, the AV data comprising a plurality of titles,comprising processing unit for executing script code or executable code;means for detecting selection of a first title read from a first storagemedium; means for detecting on the first storage medium a firstapplication associated with the first title, and an indication relatingto the first application; means for playing back the first title; meansfor executing the first application; means for terminating, upontermination of the first title, the first application if the indicationhas a first value, and otherwise continuing the first application; meansfor terminating, upon ejection of the first storage medium, the firstapplication if the indication has a certain value different from saidfirst value, and otherwise continuing the first application; means fordetecting insertion of a second storage medium; means for retrievingdata from the second storage medium; means for continuing the firstapplication if the retrieved data from the second storage medium has acertain value, and for otherwise terminating the first application;means for receiving from the executing first application a value; meansfor storing said value; means for reading, upon insertion of the secondstorage medium, from the second storage medium a second identifier;means for comparing the stored value with the second identifier; andmeans for continuing or terminating the first application depending onthe result of said comparison.